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0 A user interface builder for a user Interface server. 


0 The present invention relates generally to building or editing of user interfaces for computer systems. The 
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user interfaces created and edited are independent of any particular windowing system and do not need to be 
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CROSS-REFERENCE TO RELATED APPLICATIONS 

The present application Is related to application serial number 08/049 697 filecl on 16 April 1993. 
entitled "Dynamic Sharing of User Interfaces" by Inventors R. Wiss and J. Stucka (Docket number BT 9-92- 
5 023), Incorporated herein by reference. The present application is also related to application serial number 
08/049 700 filed on 16 April 1993. entitled "User Interface Server" by inventors R. Wiss. W. Oldfteld, and R. 
Wierwille (Docket number BT9-92-024). incorporated herein by reference. 

FIELD OF THE INVENTION 

10 

This invention relates generally to building or editing of user interfaces for computer systems. In 
particular the interactive building and editing of graphical user interfaces. 

BACKGROUND OF THE INVENTION 

15 

An application interacts with a user via a user interface. A graphical user interface (GUI) allows a user to 
interact with a computer using graphics, images, data and text together with some form of pointing device. 
The GUI is an improvement over the traditional text display and alphanumeric keyboard input device. One 
of the more popular pointing devices used by a GUI is the mouse. The mouse input device complements 

20 the keyboard which can be used for traditional text input and display. The GUI's graphical Images are 
chosen to be intuitive for ease of use, such as a push-button labeled with the image of a file cabinet to 
denote the action of saving a file. Individual components of the graphical user interface, such as a particular 
window or a push-button, are selected by using the mouse or any other supported pointing device. Other 
pointing devices include tablets, touch screen, touch screen overiays, track balls, joy sticks, light pens, 

25 thumb wheels etc. 

A window management system provides many of the important features of modern user computer 
interfaces. 

A window management system allows multiple applications to Interact with the use r on a single computer 
display, and provides low level functions for the application to display data an d collect input from the user. 

30 The window management system permits application programs to show results In different areas of the 
display, to resize the screen areas In which those applications are executing, to pop-up and to pull-down 
menus. The window management system is a resource manager In much the same way that an operating 
system Is a resource manager, only the types of resources differ. The window management system 
allocates the resources of screen area to various applications that seek to use the screen and then assists 

35 in man aging these screen areas so that the applications do not interfere with one another. The window 
management system al so allocates the resources of interaction devices to applications that require a user 
Input and then routes the flow of input information from the devices to the event queue of the appropriate 
application for which the Input Is destined. 

The look and feel of the user computer interface is determined largely by the collection of interaction 

40 techniques provided for it. Designing and Implementing interaction techniques f or each individual applica- 
tion would be a time consuming and expensive task. Furthermore, each application would end up with a 
different look and feel making it difficult for a user to move from one application to another. Applications 
sharing a common window management system can utilize a common Interactive technique toolkit built for 
the window management system to assure a common look and feel. An interactive technique toolkit 

45 consists of a set of subroutines that provide different types of display objects. 

Interactive technique toolkits, which are subroutine libraries of interaction techniques, are mechanisms 
for making a collection of techniques available for use by application programs. By using interactive 
technique toolkits, a consistent look and feel among application programs sharing a common window 
management system can be insured. Using the same toolkit across all applications is a commonly use d 

50 approach for providing a look and feel that unifies both multiple applications and the window environment 
itself. For instance, the menu style used to select window operations should be the same style used within 
all applications. Interactive technique toolkits are available for specific windowing management systems. 
Basic elements of the toolkit can include menus, dialog boxes, scroll bars, file selection boxes and the like, 
all which c an be conveniently implemented in windows. 

55 Most GUrs are developed on a personal computer or workstation using an interactive design tool (IDT), 
which responds in real time to the application developer's requests. There are several interactive design 
tools available (i.e.. Builder Xcessory for OSF/Motif and Xt Intrinsics based user interfaces. Easel for 
Presentation Manager. Aix Interface Composer and UIM/X). A "what you see is what you get" (WYSIWYG) 
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Interface Design Tool allows the application developer to see how the final user interface will actually look 
as he or she is developing it. (As another example of a WYSIWYG application, a WYSIWYG text editor 
shows the final form of a document as you are creating it. rather than requiring a separate formatting step to 
see what the text will actually look like when it is printed.) The Interface Design Tool is based on a particular 
5 windowing system with a particular interactive toolkit. The user interface developed using an IDT is the n 
compiled with other application functions to yield the application. The user interface created by the IDT for 
a given application will only work with the window management system supported by the IDT. Also, the IDT 
generates code as output. This code must be compiled and linked to the application in order to run the 
application's user interface. 

10 Changes are required to the application in order to permit the application to r un its user interface under 
a different window management system then that supported by the IDT. Thus, to run an application 
developed for one windowing system in a different windowing system, the application developer must 
rewrite the part of the application that communicates with the windowing system. Thus, the developer 
modifies the output of the IDT to make it work with the new window management system. Altematively, the 

IS developer could also use an IDT that provides support for the new window management system to recreate 
the user interface. Current IDT's do not provide a user interface that can be used with multiple window 
management systems without requiring compilation of the user interfaces they output. 

As was stated previously, the application developer could write or rewrite the user interface portion of 
an application each time the application was required to work with a different wind ow management 

20 systems. In addition to requiring rewriting of the user interface, it also requires the application developer to 
know the specialized window management system commands and be able to write in a compiled language. 
It also results in different versions of the user interface for different window management systems. This 
leads to maintenance and change control problems. 

The application developer could also use a tool such as extensible Virtual Tool kit (XVT), available from 

25 XVT software Boulder Colorado. This tool allows the developer to generate a high level description of a user 
interface consisting of high level user interface commands. Portability is provided by compiling the high 
level user interface commands, generated by the tool, into commands for the desired windowing manage- 
ment systems. This alternative results in duplicate representations of the same user interface for different 
window management systems, and requires a separate compilation step for each window management 

30 system. 

The IDT's also do not provide support for interpretive applications. The IDT's generate source code that 
must be compiled in order for the application to make use of the user interfaces created with the IDT. This 
compilable representation of the user interface does not allow an interpretative application to directly use 
the compiled user interface. In order for the application to make use of the user interfaces created by the 
35 IDT, some form of communication must be provided from the interpretative application to the compilable 
representation of the user interface. This requires the application developer to have knowledge o f a 
compiled language such as C. and to know how to tie that language to the interpretive environment. 

SUMMARY OF THE INVENTION 

40 

The present invention is directed to a method and apparatus that satisfies these needs. 

It is an object of the invention to simplify the creation and maintenance of user interfaces. 

It Is an object of this Invention to create user interfaces that are independent of any particular 
windowing system or interactive toolkit. 
45 It is another object of this invention to edit user interfaces that are independent of any particular 
windowing system or interactive toolkit. 

It is therefore an object of this invention to simplify the development of user interfaces and their 
applications. 

It is a further object of this invention to simplify the maintenance of user interfaces and their 
50 applications. 

It is an object of this invention to provide for an application to be written s o that it can be easily run 
with a variety of different window management systems without revising the application* s source code. 

It is yet another object of the invention to provide for the dynamic loading of portions of a user 
interface. 

55 It is still another object to provide interpretive applications with windowing management system support. 
It is another object of the invention to provide for a common look and feel across applications 
regardless of the platform or window management system implementation. 
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The foregoing and other objects of the invention are accomplished by an apparat us and method 
providing for an interface editor that creates user interfaces and stores the user interfaces in a display 
object store. The interface editor also retrieves user interfaces from the display object store, editing the 
retrieved user interface and storing the edited user interface in the display object store* The interface editor 

5 provides for the interactive design of a user interface with a WYSIWYG representation of the user interface 
being designed and a hierarchical representation of the user interface components. The interface editor 
permits the developer to add user Interface components in the existing user interface component hierarchy, 
to delete user interface components or groups of user interface components (i.e., sub-hierarchies or sub- 
trees of user interface components), to move user interface components and group of user interface 

10 components, to copy user interface components and group of user interface components and to change the 
resource values associated with individual user interface components. It allows for user interfaces to be 
independent of the windowing system. Applications utilize the user interfaces stored in the display object 
store via a user Interface server. The user interface server loads interfaces and supports the interaction 
between the user and the application such that a) a mechanism is provided for the application to 

fs dynamically modify and query user interfaces loaded by the user interface server from the display object 
and b) permits different applications to share the same user interface. This invention isolates the application 
from the details of the particular windowing system, so that the sam e version of the application can be run 
on different windowing systems. This is accomplished by tying together the interface editor and the user 
Interface server through a single interface representation that is independent o f the windowing system 

20 stored in a display object store. This also supports applications that run in an interpretive environment, and 
provides a way to develop and run user Interfaces without compilation. 

BRIEF DESCRIPTION OF THE DRAWING 

25 These and other objects, features, aspects, and advantages of the present invention will become better 
understood with regard to the following description, appended claims and accompanying drawings where: 

FIG la Is an architectural block diagram of a computer system depicting the memory having read therein 

a series of applications, a interface editor, a user interface server, a display object store, window 

management and an operating system. 
30 FIG lb Is an architectural block diagram of a computer system depicting the memory having read therein 

a Interface editor, a display object store, window management and an operating system. 

FIG 1c is an architectural block diagram showing three separate interconnected computer systems. 

FIG 2a shows a block diagram depicting the functional interrelationships of the Interface editor, display 

object store, user Interface server and window management system. 
35 FIG 2b shows a block diagram depicting the functional relationships of the interface editor, the display 

object store and the window management system. 

FIG 2c shows a block diagram depicting the functional relationships of the interface editor, display object 

store for a particular window management system. 

FIG 3 shows the display object store with several interfaces. 
40 FIG 4 shows a high-level data flow diagram for the Interface editor. 

FIG 5 shows the user interface for the Interface editor. 

FIG 6 shows the primary window of the interface editor. 

FIG 7 shows the edit menu of the interface editor. 

FIG 8 shows the active interface window of the interface editor. 
45 FIG 9 shows the active component resource window of the interface editor. 

FIG 10 shows the text resource editor dialog of the interface editor. 

FIG 1 1 shows the color resource editor dialog of the interface editor. 

FIG 12 shows selection of the 'menu bar' component type from the component creation control panel in 
the primary window of the Interface editor. 
50 FIG 13 shows selection of the 'menu choice' component type from the component creation control panel 
in the primary window of the Interface editor . 

FIG 14 shows the primary window after the 'menu choice* component type has been selected. 

FIG 15 shows the active interface window of the interface editor with the menu bar and menu choice 

displayed. 

55 FIG 16 shows the edit menu choice label in the active component resource window of the interface 
editor. 

FIG 17 shows the active interface window of the interface editor with the menu bar and menu choice 
displayed after editing the menu choice's label. 
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FIG 18 shows the active interface window of the interface editor with the menu bar and additional menu 
choices. 

FIG 19 shows the primary window of the interface editor with the menu bar and additional menu choices. 
FIG 20 shows the user interface for the interface editor. 
5 FIG 21 shows the primary window with the pull down menu and pull down menu choices added. 
FIG 22 shows selection of test mode in the primary window of the interface edit or. 
FIG 23 shows the active interface window in response to selection of the 'RIe' choice in the active 
interface window in test mode. 

FIG 24 shows the interfaces pulldown menu from the main menu of the primary win dow of the interface 
10 editor. 

DETAILED DESCRIPTION OF THE INVENTION 

DEFINITIONS 

75 

"User Interface" is a hierarchy of user Interface components. A user interface contains user interface 
components that comprise a graphical user interface. The term user interface may refer to the actual 
appearance on the display or a representation in worl<lng memory or a representation in the hierarchy may 
t>e a multi-level hierarchy with children having children. The root component is typically a primary window 

20 component. All other display components are children of the root. They may all be first generation children 
(I.e., a two level hierarchy) or multi-generational (i.e. mo re than two levels). The components are structured 
in a hierarchy, also referred to as a tree. An example of such a structure is a 'family tree' of genealogy. The 
components of the tree are connected to other tree components. T ree components can have a 'parent' (the 
component it belongs to) and 'children' (components that belong to it). A sut>-hierarchy, or sut>-tree, is any 

25 specified component and all the children under it including children's children, and so forth. 

"User Interface component" this term refers to the individual visual pieces of the interface or a 
representation thereof. A component can be either a high level component (i.e, a window) or a low level 
component (i.e, pushbuttons, menus, and text labels). Components may also be categorized by their 
relationship to other components. Container components refer to components that contain or control other 

30 components. Container components are described as being parents of the components that are within their 
control or within their physical boundaries. Primitive components make up the lowest level of a given 
hierarchy or sub-hierarchy and cannot contain other components. Composite components are groupings of 
container components and primitive type components. 

"Resources" are associated with a user interface component. Resources refer to specific attributes of a 

35 given component. Examples of resources include Its foreground color, background color, name, font, parent, 
pixmaps, Icons etc. Some resources are common to all components, some are common to a sub set of 
components, and some are specific to a given type of component. 

"Callbacks" are a special class of resources. Callbacks provide a means for associating application 
specific functionality with a user Interface component. A callback is associated with a p articular user action 

40 in a component. Each component type which is responsive to user input supports one or more callback 
types. For example, an application would typically have some processing to perform when a user selects a 
push button displayed in the application's user interface. Typically two resources are specified for a 
particular callback type: the callback and the callback data. The application developer specifies the call 
backs required for the user interface when the application is created. The name of the application function 

45 for callbacks is stored with the user interface components in the display object store but can be modified by 
the application. "Display Object' Is a data abstraction representing a visual characteristic or the visual 
characteristic itself. A display object can be a plurality of user Interfaces, a single user interface, a plurality 
of user interface components, a hierarchy or sub-hierarchy of user interface components, a single user 
interface component or a resource such as a pixmap or icon. 

50 "Command" includes the instruction to be executed along with any required data . For instance, a load 
command must specify the user interface to be loaded. The required data for the load command may 
consist of the name of the user interface or a reference to another location that contains the name or a 
reference to the user interface itself. 

55 OVERVIEW 

The preferred embodiment of this Invention comprises a set of computer programs for controlling the 
interaction between a user and a computer system as shown in the architectural b lock diagram of FIG la. 
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FIG la includes a central processing unit (CPU) 20 connected by means of a system bus 22 to a read only 
memory (ROM) 24 and a random access memory (RAM) 38. Also included in the computer system in FIG 
la are a display 28 by which the computer presents information to the user, and a plurality of input devices 
including a keyboard 26, mouse 34 and other devices that may be attached via input/output port 30. Other 

5 Input devices such as other pointing devices or a voice sensors or image sensors may also be attached. 
Other input devices and pointing devices include tablets, numeric keypads, touch screen, touch screen 
overlays, track balls, joy sticks, light pens, thumb wheels etc. The I/O 30 can be connected to communica- 
tions lines, disk storage, input devices, output devices or other I/O equipment. 

The interface editor 49 is located in RAM 38. The interface editor 49 permits a developer to 

10 interactively create user Interfaces and store the created user interfaces in a display object store 46. The 
interface editor 49 also retrieves user interfaces from the display object store 46, editing the retrieved user 
interface and storing the edited user interface in the display object store 46. The interface editor provides 
for the interactive design of a user interface with a WYSIWYG representation of the user interface being 
designed and a hierarchical representation of the user interface components. The interface editor 49 permit 

Y5 s the developer to add user Interface components In the existing user interface component hierarchy, to 
delete user interface components or groups of user interface components (i.e., sub-hierarchies or sub-trees 
of user interface components), to move user interface components and group of user interface components, 
to copy user interface components and group of user interface components and to change the resource 
values associated with individual user interface components. It allows for user interfaces to be independent 

20 of the windowing management system 58. 

Applications 50, 53. 54 utilize the user interfaces via a user interface server 48. By isolating the application 
from the details of the particular windowing system, the same user interface can be run on different 
windowing systems. The Interface editor 49 utilizes a window management system interface 70 to provide 
access to the window management system 58. This enables the interface editor 49 to present and control 

25 the behavior of Its user Interface. It is the Interface editor's user interface that allows the developer to create 
and edit user interfaces for applications. The interface editor 49 is also coupled to the Display Object Store 
46. The interface editor 49 can read user interfaces from the display object store 46 or write user interfaces 
to the display object store 46. 

The RAM 38 includes application A 50, application B 53, application Z 54. Each of tiiese application 

30 programs utilizes a user interface server interface 52. The user interface serve r interface 52 allows 
applications to access functions and data contained in the user interface server 48. Examples of typical 
application programs would include a word processor, spreadsheets, graphic programs, electronic mail and 
data base programs. Also located In RAM 38 is the user interface server 48. The user interface server 48 
utilizes a window management system interface 70 to provide access to the window management system 

35 58. A display object store 46 contains user interfaces with each user interface containing a plurality of user 
interface components. The user Interface server retrieves user interfaces and portions of user interfaces 
from the display object store 46 in response to application comnriands. 

An operating system 74 Is also included in RAM 38. Examples of operating systems include AIX] and 
OS/2]. The RAM 38 includes a window management system 58 such as the X window management 

40 system] for AIX] or Presentation manager] for OS/2. It is the operating system 74 in con junction with the 
window management system 58 that allows applications to be running concurrently and to share the same 
interaction devices. It is the user interface server 48 in conjunction with the display object store 46 that 
permits sharing of user interfaces and portions of user interfaces. It is the interface editor 49 tiiat allows the 
developer to create, modify and delete user Interfaces in the display object store 46. Other element s 

45 shown in RAM 38 include drivers 76 which interpret the electrical signals generated by devices such as t he 
keyboard and mouse. 

A Working memory area 78 is also shown in RAM 38. The Working Memory Area 78 c an be utilized by 
any of the elements shown in RAM 38. The working memory area 78 can be utilized by t he applications 
(50, 53, 54), window management system 58, user interface server 48, interface editor 49, Operating 

50 System 74 and other functions. The working memory area 78 may be partitioned amongst the elements an 
d within an element. The working memory area 78 may be utilized for communication, buffering, temporary 
storage, or storage of data while a program is running. For instance, the interface editor 49 utilizes the 
working memory area 78 for loading and operating on user interfaces retrieved from the display object store 
46. The working memory area 78 may also be utilized by the operating system for multi-tasking purposes. 

55 The working memory area 78 can be included as part of the application or it may be located in a common 
area. In either case there is no requirement that the working memory be contiguous in RAM 38. 

The interface editor 49 and the user interface server 48 do not need to be located on the same 
computer system. FIG lb depicts a computer system with the interface editor 49 without the user interface 



6 



EP 0 622 729 A2 



server or the applications. The descriptions of the elements for FIG la are the same for those in FIG IB. 
The display object store 46 Is shown in FIG lb. However, as is shown in Rg 1c» the display object store 
can be located on a different computer system then either the Interface editor 49 or the user interface 
server 48. Thus, the display object store 46 could be located on a file server with the interface editor 49 

5 having read and write privileges and the user interface server 48 have read only privileges. FIG 1c shows 
the three Interconnected computer system with the Interface editor 49 located on system 1, the display 
object store 46 located on system 2, and the user Interface server located on system 3. The systems could 
be interconnect by any standard computer network such as token ring or a local area network. 

FIG 2a shows the functional relationships between the user interface server 48 coupled to the 

70 applications 50. 53, 54. the window management system 58, and the display object store 46 and also shows 
the interface editor 49 coupled to the window management system 58. and the display object store 46. FIG 
2b shows the interface editor 49 coupled to the window management system 58, and the display object 
store 46. 

The communication means 56 provides for the two way communication between the interface editor 49 

75 and the window management system 58. The communicating means 56 also provides for two way 
communication between the user interface server and the applications and between the user interface 
server and the window management system. Interconnecting means 56 can be inter-process communica- 
tions as provided by the operating system 74 or an alternative such as procedure calls or shared memory. 
Note that although the Interconnecting means are labeled with same number In FIG 2a and FIG 2b, the 

20 interconnecting means are not required to be the same for each link. 

The interface editor is coupled to the windowing management system 58 by interconnecting means 56. 
The user interface server 48 also is coupled to the windowing management system 58 b y interconnecting 
means 56. The window management system 58 provides the display management functions such a s 
displaying data and collecting input from the user via the input means. The Interface editor 49 and user 

25 Interface server 48 both use the window management system Independently of each other. As was shown 
in FIG 1c the user interface server 48. interface editor 49 and the display object store 46 can be located on 
separate interconnected systems. The interface editor 49 and User interface server 48 are not directly 
coupled to each other. The user interface server 48 can utilize user Interfaces stored in the display object 
store 46 by the Interface editor 49. 

30 The Interface editor 49 and user Interface server 48 communicate with the window management system 
via the Window Management System Interface 70. This window management system interface 7 0 is part of 
the interface editor 49 and the user interface server 48 and is dependent on the particular window 
management system 58 selected. Note that the user Interface server 48 and the interface editor 49 may use 
entirely different window management systems. The interface editor 49 creates and edits user interfaces for 

36 storage and retrieval in the display object store 46. The interface editor could be implemented using any 
win dow management systems. The user interface server 48 makes use of the user interfaces stored in the 
display object store 46. It displays these user interfaces in response to commands sent from the 
applications it services. The user interface server 48 displays and controls the user Interfaces using the 
windowing system. As long a s the user interface server 48 is ported to a window management system the 

40 developer using the interface editor 49 , using an entirely different window management system, can create 
user interfaces for use by the user Interface server. The Interface editor 49 allows the developer to create 
interfaces for any windowing management system to which the user interface server 48 has been ported. 
The same user Interface that is stored in the display object store 46 can be utilized with any number of 
different window management systems. The interface editor permits the creation of user iriterfaces that are 

45 independent of any window management system. This is a great advantage of the Invention. By placing 
window management system specific functions in the user Interface server, the applications are free from 
particular window management system dependencies. 

The window management system interface 70 may consist of a set of library routines for Interfacing 
with the window management system or a higher level interaction toolkit or both. An example for the X 

50 Windows system is shown in Fig 2c. Note that the interface editor 49 and the user interface server 48 may 
use different window management systems and may use different window management system Interfaces. 
Thus, the user Interface server may use an interaction toolkit while the interface editor may use no tool kit 
at all. 

55 THE INTERACTIVE INTERFACE EDITOR 

The interface editor provides for the Interactive creation and editing of user interfaces. The user 
interfaces created In this way are independent of any particular windowing environment. The interface editor 
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allows application developers to interactively define user interfaces. Support Is also provided for associating 
application callbacks with the user interface components of a user interface. The product o f the interface 
editor is the display object store representation of the application's user interface. The developer via the 
interface editor can store, retrieve, and delete interfaces from the display object store. Once an user 

6 interface is retrieved from the display object store, or created from scratch, it can be interactively 
manipulated by the developer in a What You See Is What You Get (WYSIWYG) fashion and returned to the 
display object store with any updates. These manipulations Include user interface component creation, 
modification, and deletion. The interface editor permits the developer to add user interface components in 
the existing user interface component hierarchy, to delete user interface components or groups of user 

10 interface components, to move user interface components and group of user interface components, to copy 
user interface components and group of user interface components and to change the resource values 
associated with individual user interface components. The display object store versions of user interfaces 
are then loaded by the user interface server to create the run-time interface when an application is invoked. 
The interface editor has its own user interface, completely distinct from the user interfaces stored in the 

15 display object store and used by the user interface server. Although, the Interface edit or could utilize the 
user interface server for its own user interface. The only run-time interface between the Interface Manager 
and interface editor is an indirect one. through the display object store. This is shown in Rg 2a, 

The interface editor provides an object-oriented technique for interactive use r interface development. 
The developer interacts with the interface editor through several independent window s. The interface editor 

20 supports development of one active interface at a time. There is no limit to the number of components that 
can be created for a given interface. The resources which can be modified for a given component are fixed 
and depend upon the component type. 

The interface editor supports two modes of operation, design mode and test mode . The distinction lies 
in the reaction to input in the Active Interface Display (i.e, the WYSIWYG representation of the user 

25 interface under development). These modes affect how user interface events are handled during the 
interface editor session. In the first mode, 'design mode', the default windowing management system 
response to the user interface components in the active display window are replaced with interface editor 
responses. In the second mode, 'test mode', the user interface components exhibit their default 3-D 
behavior. For ex ample, in design mode, the user can click on a pushbutton, in the active display window, in 

30 order to select that pushbutton for the attribute updates. In test mode, clicking on the same pushbutton will 
cause it to look as if has actually been pressed. Similarly, clicking on a menu bar choice in test mode will 
cause the associated pulldown menu to appear, while clicking on it in design mode will select the pulldown 
menu component for update . 

The interface editor supports mouse and keyboard manipulation of its user inter face. All functions can 

35 be accessed through the mouse or the keyboard, using the standard methods for input device interaction. A 
brief description of one embodiment of the keyboard access to the interface editor Is as follows: 
0 Press ALT-tab to move between the interface editor windows, 
o Press the F10 key to move the location cursor to the menu bar. 

0 Use the Left and Right arrow buttons to move the location cursor between menu bar choices. The left 
40 and right arrows also move the location cursor between components in the hierarch y display area. 

0 Use the up and down arrow buttons to move the location cursor between items i n a pulldown, popup 

or option menu. Also use the up and down arrow to move between the buttons in the component 

creation control panel. 

0 To scroll the hierarchy display, position the location cursor In the scroll bars and use the up and down 
45 arrow keys. 

0 Select an item in a menu by moving the location cursor to the desired choice (as described above) 
and pressing the enter key. An easier way to select a menu choice that has a mnemonic defined is to 
navigate to the menu, and then press the key defined as the mnemonic for the desired menu choice. 
Alternatively, press ALT-and the mnemonic to select a menu bar choice without first moving the 
50 location cursor to the menu bar. 

0 Use the tab keys to move between the menu bar, the component creation buttons , the scroll bars 
and the hierarchy display in the primary window. 

0 To avoid selecting any of the choices when a pulldown, popup or option menu I s displayed, press 
Esc key. 

55 The following paragraphs describe the one embodiment of functional processes that comprise the high 
level data flow of the interface editor. Persons of ordinary skill in the art will recognize that alternative 
functional decompositions can be created to carryout the Invention. Note, the term process is used in this 
section in the DeMarco methodology sense rather than In the UNIX process sense. A high level da ta flow 
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diagram for this embodiment is shown In FIG 4. 

This embodiment of the interface editor consists of the following processes: interface editor Control. 
Interface Manager. Resource Manager, and Component Manager. Each of these functions is described 
below. 

5 interface editor Control is the top level process. It creates and manages the interface editor's user 
interface. The interface editor's user interface allows the developer to Interact with the interface editor. The 
interface editor Control process Interprets events from the develof)ers's manipulation of the interface editor's 
user interface, and responds by invoking other components of the Interface editor to handle specific tasks. 
The Interface editor Control process also handles asynchronous enrors encountered on behalf of the 

10 interface editor In the Window Management System. 

The Interface Manager process provides the functions which operate on the external display object 
store representations of the user Interfaces. It manages the display object store Interface and invokes the 
operations which transform the display object store representation into the internal representation (and vice 
versa). The interface Manager process provides the functions that operate on the representation of user 

75 interfaces in the display object store and provides the functions to load interfaces from the display object 
store Into the working memory area and save user interfaces that were created or modified in the working 
memory to the display object store. 

The Component Manager process provides the functions which operate on an intern al Interface 
representation at the component level, Including component creation, deletion, and modification . The 

20 Component Manager process provides the functions to display, dynamically query and modify the user 
interface and particular user Interface components and the relationship of user interface components within 
the user interface being created or edited. 

The Resource Manager process provides functions that manipulate component resource lists and allow 
interactive editing of individual resources for an active interface component. The Resource Manager 

25 process also provides functions to convert resource data between the intemal and display object store 
formats. The Resource Manager process provides functions that manipulate the resources of a component 
of the user interface being created or edited. 

TABLE II show high level pseudocode for this embodiment of the interface edit or. 

30 



35 



40 



45 



so 



55 
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TABLE II 
main: 
initialize: 

call initialize_control 

call initialize_resource manager 

call initialize_storage manager 

call initialize_component manager 
process_edi t_session : 

until user done 

call handle_user_request 

loop 
exit: 

call terminate_resource_manager 
call terroinate_storage_manager 
call te]nninate_component_manager 
call terroinate_control 
return 

initialize_control : 

initialize interface to windowing system and Motif toolkit 
load and init Editor Interface user interface 

create default user interface (primary window with default 
attribute values) 

display interface editor user interface and default user 
interface being created 

return 

terminate_control : 

terminate connection to window manager and Motif toolkit 
return 

initialize_resource_editor : 
register callbacks for user interface units 
return 

initialize_component_manager : 

retrieve text portions of user interface based on current 
language (e.g., English, French, etc.) 
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retrieve default attribute values 
retrieve fonts and colors 
5 return 

terminate^coinponent : 
free fonts and color resources 

70 

return 

initialize_stor age^manager : 
retrieve bitmaps 
return 

20 handle_user_request : 

determine_user_request 

Process_user_request 
25 return 

The interface editor can be Invoked through a start_interface_edltor command. This command. In tum, 
invokes the interface editor's user interface. The start__interface_editor command is typically accessed 
30 through an icon in the Generic Application, although it can also be entered directly through the command 
line. 

Upon invocation the interface editor is displayed and the interactive session t)egins. If an user interface 
was specified In the start_interface_edltor, and the specified user interface cannot be loaded, the user will 
be notified of the enror and the session will begin with the default Interface primary window. 
' 35 After processing the interface parameters and user preferences, the interface editor displays: the 
Primary Window 90, the Active Interface Window 95, and the Active Component Resources Window 96. 
The windows are shown on the display 28 in Fig 5. The windows are described as follows: 

o Primary Window 90 - This window contains the Interface editor main menu 91, the status line 92, the 
component creation control panel 93 and the component hierarchy display area 94. The main menu 
40 91 provides access to Interface functions, edit functions, clipboard functions, user preferences. 

viewing options, and help functions. The component creation control panel 93 contains a set of 
pushbuttons, one for each component type supported by the interface editor (i.e.. secondary window, 
dialog box. menu bar, explicit group. Automatic group, pulldown menu, popup menu, option menu, 
menu choice etc.). The component hierarchy display area 94 shows an at-a-glance view of the 
45 components in the current active interface and the relationships between them. The component 

hierarchy display area also allows the developer select a component for manipulation. Selection 
means that a component's resource list is displayed, it becomes the active parent, if applicable, for 
the subsequent creation requests, and edit operations (cut and copy) will apply to the component. 
0 Active Interface Window 95 - This is the WYSIWYG display of the user interface under development 
50 and corresponds to the hierarchy of user Interface components as shown In component hierarchy 

display area. 

0 Active Component Resources Window 96 - This window displays a list of the resource names and 
values for the active component. The resources are displayed as. a group of radio buttons so that the 
developer can select one for modification. Selection of a resources prompts the display of a resource 
65 editor appropriate to the type (color resource. Integer resource, text resource, etc .) of resource 

selected. Modification of a resource value is Immediately reflected by the component in the Active 
Interface Window 95 and if appropriate in the component hierarchy display area 94 (i.e. , when a label 
resource Is modified). 
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0 The developer can also Interact with other windows that are used for error messages, dialog boxes, 
and resource editors. 

The Active Component Resources window 96 Is not required and may be removed from the display by 
the user. The other two main interface editor windows (the Primary Window 90 and the Active Interface 
5 Window 95) are always displayed. Other windows In the form of dialog boxes are display ed as the result of 
specific requests from the user in the three main windows. These dialog boxes are remove d from the 
display by the interface editor on completion of their particular task. The following paragraphs describe the 
purpose of and Interactions with each of the main windows and dialog boxes of the Interface editor's user 
interface. 

10 The interface editor's primary window 90 is shown in FIG 6. It consists of four pieces: a menu bar 91, a 
status line 92. a scrolled list of options for component creations 93, and a display of the component 
hierarchy corresponding to the current user-defined Interface in the component hierarchy display area 94. 
The menu bar 91 contains the following choices: Interfaces, Edit, View, Options and Help. Associated with 
each choice of the menu bar is a mnemonic which is shown in FIG 6 as the underscored letter of each 

75 choice. The mnemonic Is a single letter which allows the user to select the specific menu bar choice from 
the keyboard when the menu bar is active. Also, each of the pulldown menus associated with the menu bar 
contains mnemonics for each choice in the pulldown menu. These choices may be selected from the 
keyboard when the pulldown menu is displayed. See FIG 7. 

The Primary Window Menu Bar 91 provides for the following choices of types of actions as follows: 

20 Interface actions. Edit Actions, View Actions and Options actions. The actions a re discussed below 

The Interface Actions appear on a pulldown menu when Interfaces is invoked, the functions available 
correspond to the standard File actions such as NEW. OPEN. SAVE, SAVE AS. DELETE . PRINT and EXIT. 
See FIG 24. 

0 NEW allows the developer to begin creation of a new interface. The developer is prompted for 

25 confirmation If modifications to the current interface have not been saved. The new interface, 
consisting of an empty Primary Window, is untitled and is displayed in the Active Interface Window. 
0 OPEN allows the developer to choose an existing interface to load from the display object store. The 
developer may either select an user interface from the list displayed in the scrolled window, or type a 
name in a 'Selection* entry field. The user interface choices are displayed alphabetically in the 

30 scrolled list and are obtained by using either a library area or a search path as a filter. After selecting 

an interface, the developer clicks on the OK button to actually initiate the open. The open operation 
can also be initiated by double clicking on one of the user interfaces listed in the open interface 
dialog. If unsaved modifications are present for the existing Interface, the developer Is prompt ed for 
confirmation before loading the new interface. The developer may click on the Cancel button to exit 

35 the Open Interface dialog without opening an interface. 

o SAVE stores the current interface to the display object store. The default display state of each 
interface component is saved with the interface. This resource determines whether or not that 
component is displayed when its parent is displayed at application run time. The state of the interface 
when it is saved determines the default display state settings: those components that are not 

40 displayed when the interface is saved will by default not be displayed when the interface is loaded. 

For example, suppose the application developer creates push button A, does an Undisplay for push 
button A and then saves the interface. When the interface is loaded at application run time, push 
button A will not be. displayed automatically when Its parent is displayed. NOTE: The application can 
change the default display state run time, so that push button A is displayed with its parent; such a 

45 change affects only the executing copy of the interface, not the display object store copy. 

0 SAVE AS stores the current Interface to the display object store using interface name provided by the 
developer. The interface names are initialized with the current values when the dialog is displayed; the 
developer may update them or continue with the current name and library area. If the interface name 
specified already exists in the display object store, confirmation is request ed before the previous 

50 copy is overwritten. The interface is renamed, the Active Interface Window is update d with the new 

interface name, and subsequent saves apply to that name. 
0 DELETE allows the developer to delete an Interface from the display object st ore. Except for Its title, 
the Delete Interface dialog is identical to the Open Interface dialog. The Inter face to be deleted Is 
selected from a list of those available, and the developer clicks on the OK button. T he developer 

55 must respond to a confirmation prompt before the interface is actually deleted. The current interface 

Is the default selection; 

when the current Interface is deleted, the Active Interface Window is initialized with an empty Primary 
Window. 
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0 PRINT allows the developer to create a screen dump of the current user Interface. 

0 EXIT ends the Interface editor session. The developer Is prompted for confirmation If the current 

interface has been modified since it was last saved to the display object store. 
The Edit Actions allow the developer to manipulate user interface components within the active 
5 Interface. The Interface editor Edit Menu Is shown In FIG 7. The component hierarchy display area 94 Is 
used to select those components of the interface on which to perform edit operations. An accelerator can 
be associated with each Edit action, some accelerators are to the right of each Edit action. The accelerator 
is a key sequence which the developer may use to invoke the associated action instead of using the mouse 
to display and traverse the Edit menu to select the desired edit action. The accelerators shown are merely 
10 examples. Some editing actions are defined below. 

0 UNDO reverses only the most recent cut, paste, move, or resize operation. For example, if the 
developer cuts a user interface component(s) from the user interface followed by a cut of another user 
interface component(s), the developer can only undo the most recent cut operation since it was the 
last one to be performed. The clipboard Is unaffected by the undo operation. The Undo menu choice 
75 Is appended with the most recent of the cut, paste, move, or resize operations so that the developer Is 

aware of the type of operation to be undone. If a cut, paste, move, or resize operation has not been 
performed for the current interface, the Undo menu choice is unavailable; it has nothing appended, 
and is grayed out. 

- UNDO CUT restores the portion of the user interface previously cut. 

20 ' UNDO PASTE removes the pasted user interface components from their new location. 

- UNDO MOVE restores the user interface component to its previous x and y location. 

- UNDO RESIZE restores the user interface component to its previous height and width. 

For undo cut, if the parent-child pairing is no longer valid due to user interface components added or 
deleted since the last cut operation, an enror message is Issued and the undo operation is not performed. 

25 0 CUT removes the selected user Interface components, placing them In the clipboard. The previous 
contents of the clipboard are overwritten with the newly cut user Interface components. Note: The 
primary window can not be cut (since every interface must contain a primary window). The cut option 
Is made Insensitive when the primary window Is the active component. 
0 COPY duplicates the currently selected user interface component, including it s children, into the 

30 clipboard, without removing the original components from their current location. The previous contents 

of the clipboard are overwritten with the newly copied user interface components. Note: The primary 
window can not be copied (since every interface contains exactly one primary window). T he copy 
option will be made insensitive when the primary window is the active component, 
o PASTE copies from the clipboard to the user interface and empties the clipboard. The currently active 

35 parent user interface component is used as the parent for the pasted user interface component or 

group of components. If the parent-child pairing is not valid (due to inconsistent types, for example), 
an error message is issued and the user interface components are not pasted. If any o f the user 
Interface components being pasted have the same name as another user interface component in the 
interface, the pasted component's name will be changed to a default name. 

40 0 MOVE allows the developer to interactively move the user interface component within the bounds of 
its parent. Selection of this option moves the mouse cursor to the upper left ha nd corner of the user 
interface component. In test mode, moving the mouse also moves the component. In design mode, a 
rubber band box will appear for a primary window, secondary window, dialog box, or message dialog. 
The rubber band box will move to show the new position of the user interface component. This allows 

45 the developer some flexibility to see the entire active interface during creation without affecting the 

runtime position values. The developer will have to switch to test mode to see the runtime positions of 
all the windows in the active interface. For the remaining user interface components, moving the 
mouse in design mode also moves the user interface component. Clicking any mouse button 
terminates the move operation and updates location resources (x and y) for the component. 

50 0 RESIZE allows the developer to interactively resize a user interface component within the bounds of 
its parent. Selection of this option places the mouse cursor In the lower right hand corner of the user 
Interface component. A rubber band box anchored In the top left is then displayed to preview the 
resize operation. Clicking any mouse button terminates the operation, resizes the user Interface 
component and updates the height and width resources of the user inter face component. 

55 0 SNAP CURRENT COMPONENT TO GRID moves the current user interface component to the grid 
intersection nearest to its upper left corner. 
0 SNAP CHILDREN TO GRID moves each child of the current user interface component to the grid 
Intersection nearest to the upper left comer of the child user interface component. The grid does not 
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have to be displayed. 

0 RAISE allows the developer to raise the user interface component to the top o f the displayed user 
Interface component stack. A stack of papers on a desk is a common metaphor used to descrit>e the 
relationship between window-based user interface components. In order to fully view a user Interface 
5 component that is partially or fully hidden below another user interface component, it must be raised 

to the top of the stack. This option raises a user Interface component to the top o f a stack comprised 
of that user interface component and all Its siblings. 
0 LOWER allows the developer to push the active component below other user interface components 
with the same parent. When a user interface component is lowered, all other user interface 
10 components with the same parent are displayed In front of It in the Active Interface Window, 
o DISPLAY allows the developer to display the active user Interface component, 
o UNDISPLAY allows the developer to remove the active component from the display. The user 

interface component is not destroyed by the undisplay action, just removed from view. 
The view Actions determine how the user interface components in the user interface under develop- 
75 ment are represented in the component hierarchy display area. These options allow the developer to 
determine the orientation and scale of the user interface component hierarchy tree. Changing the hierarchy 
orientation and scale will In most cases also impact which user Interface components are visible In the 
component hierarchy display area. The interface editor will adjust the display if necessary, to ensure that 
the currentiy selected component is visible following a view action. The interface editor View Menu contains 
20 the following functions. 

0 ORIENTATION allows the developer to specify the orientation of the hierarchy tree. The possible 
values are Vertical and Horizontal. Selection of the orientation menu choice will present the developer 
with a sub-menu containing the two values, 
o FULL SIZE specifies that the labels for the push buttons in the hierarchy tree are displayed in the 
25 active interface editor font and the size of the push buttons will be based on that font. 

o 1/2 SCALE specifies that the size of the push buttons in the hierarchy tree i s 1/2 the size they would 
be if displayed using the active font. The labels of the push buttons in this scale may not be readable. 
0 1/4 SCALE specifies that the size of the push buttons in the hierarchy tree Is 1/4 size they would be If 
displayed using the active font. The labels of the push buttons in this scale may not be readable. 
30 0 1/8 SCALE specifies that the size of the push buttons in the hierarchy tree i s 1/8 they would be If 
displayed using the active font. The labels of the push buttons in this scale may not be readable. 
The Options actions provide the developer with several interface editor specitic functions involving such 
things as developer preferences and grid functions. These are described below: o ACTIVE COMPONENT 
RESOURCES DISPLAY displays a pulldown menu which allows the developer to toggle the display of the 
35 active component resources window on and off. 

0 ACTIVE COMPONENT CREATION BUTTONS displays a dialog box which allows the developer to 
select which component creation push buttons are displayed in the Component Creation Control 
Panel. By setting the checklist button off, the corresponding component creation push button will not 
appear in the Component Creation Control Panel and, thus, the developer will not be able to create a 
40 component of that type until that checklist button is again activated. If all of the component s of a 

category (container, composites, or primitives) are turned off. the lat>el for that category will also not 
appear in the Component Creation Control Panel, 
o GRID displays a dialog box that allows the developer to activate and specify parameters for a grid in 
the active component. This grid can be used to position user interface component s in a consistent 
45 way inside a parent. The Grid option is available only when the active component is a primary 

window, secondary window, dialog box. or an explicit group box. A grid can be defined for each 
component of these types in the active interface. Grid settings are retained independentiy for each 
component for tiie length of the current interface editor session. Each of the fields in the grid dialog 
box Is described below. 

50 0 SNAP TO MODE presents the developer with a pulldown menu which allows the developer to toggle 
the snap to mode on and off. When snap mode is one, any child (except a secondary window, dialog 
box or message dialog box child) of a primary window, secondary window, dialog box, or explicit 
group box which is moved will automatically snap to the nearest grid Intersection when the move 

operation Is terminated. 

55 0 PREFERENCES displays a dialog box which allows the developer to modify, apply and save 
developer preferences for the interface editor. These preferences Include foreground a nd background 
color, font, grid spacing, interface search path, and pixmap search path. 
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0 DESIGN/TEST allows the developer to toggle between test and design mode for t he developing user 
interface. Design mode is the default mode for the interface editor. Select ion of the design/test mode 
menu choice presents the developer with a suk>-menu of the two modes. The current mode is 
displayed In the interface editor status line. 
5 The interface editor Help menu provides the standard features of an interactive help facility. 
The interface editor status line 92, located directly loetow the menu bar, shows the following: 
0 the current parent component 

0 whether the cunrent user interface is being manipulated in design or test mod e. 

0 whether "Snap to mode" is on or off. 
10 The Component Creation Control Panel 93 is described below. User interface component creation is 
accomplished by use of the component push button list contained within the inter face editor primary 
window. This scrolled list contains one button for each user interface component type supported by the 
interface editor. At any given time, only those component types valid as children of the active parent are 
selectable (sensitive). Selection of a sensitive component button will: 
16 o create a user interface component of that type which will be a child of the active parent. 

o the new user interface components resources will be assigned default values. 

0 place the child in a default location within the parent. 

o activate the user interface component. 

The component hierarchy display area 94 is a scrolled window which contains a representation of the 
20 cunrent active interface as a set of push button connected by line which represent parent/child relationships 
between user interface components. The push buttons which represents the primary window of t he 
interface is always the root of this tree. The buttons which represent the first level children of the primary 
window are connected to the primary window push button by a line. Each of the child push buttons is 
aligned so that their X locations are equal in the case of horizontal orientation of the hierarchy and their Y 
25 locations are equal for a vertical orientation. This scenario is repeated for each level of the component 
hierarchy. 

The component hierarchy display area is updated each time a component is added or deleted. Each of 
the following composite components is displayed in the hierarchy as several separate boxes to indicate the 
building blocl^s from which is it composed: radio box and checklist box. For example, when the developer 
30 creates a radio box, buttons for a group box and 5 radio buttons (the default number in a radio box) will be 
added to the hierarchy display. This Is done in order to provide access to the individual re sources of the 
building block components. 

Component Selection/Activation: This function allows the developer to select (activate) a single user 
interface component or a sub-hierarchy in the user interface for resource manipulation or edit operations. To 
35 select a single user interface component, the developer places the mouse cursor over the push button 
which represents the desired user interface component and clicks the mouse button. When this is done : 
0 the button foreground and background colors are reversed o the component hierarchy display area is 
re-centered on the selected user Interface component button, unless the whole hierarchy or the 
portions relevant to the selected user Interface component button are already displayed. 
40 o the Active Component Resources window is updated with the resources for the s elected user 
interface component. Note that the update occurs even If the Active Component Resources window is 
not currently displayed. 

o and the selected user interface component becomes the active parent, if applicable. If the selected 
user interface component may validly be the parent of any other user interface component type, the 
45 selected user interface component becomes the active parent. If the selected user interface compo- 
nent can not be the parent of any other user Interface component types, its parent becomes the active 
parent. 

0 The active parent is the user interface component that serves as the parent for subsequent user 
interface component creation operations. The sensitivity of the buttons in the component creation 
50 control panel is updated to reflect valid children user interface components of the active parent. 

o copy operations affect only the selected user interface component. If the component has children they 
are not copied. 

If the mouse is placed over the parent of a group of components and mouse button is double clicked, 
the entire sub-hierarchy below that parent is activated. In this case: 
55 0 the colors of all of the buttons in the hierarchy display which represent descendants of the parent are 
reversed. 

0 the resources for the parent component are displayed In the Active Component Resources window. 
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0 modifications to the foreground color, background color, font, and background pixmap resources of 

the parent are immediately propagated to the descendent user interface components . 
o copy operations will apply to the entire sub-hierarchy of user interface components. 
The Interface Editor Active Interface Window - Design Mode. The Active Interface Window 95 shows the 

5 user interface components of the user interface under development for which the display state is set to true. 
FIG 8 shows the WYSIWYG representation of the actual components represented in the component 
hierarchy display area of FIG 6. This display is updated dynamically as user interface components are 
added, deleted, or modified. Test and design mode determine the reaction to input in this window. When In 
design mode, pressing the mouse button 1 with the pointer over a visible user interface component in the 

TO active Interface window will activate the user Interface component. Pressing mouse button 2 will display a 
po pup menu with the edit options available for the active component. The edit options available in the 
popup men u are the same options available on the edit menu in the interface editor Primary Window. Also 
in design mode, when the window manager is used to move a primary window, secondary window, dialog 
box, or message dialog, the user interface component will physically move on the screen but the 

15 component's x and y resources will not be updated. This allows the developer greater ease in viewing all of 
the active interface's windows during creation without affecting the runtime position attributes. When these 
component's x and y resources ar changed via a move operation or the resource editor, the component will 
not physically move. Instead, a rubber band box will be displayed showing the new position of the 
component. Once the move operation is terminated or the resource editor is removed, the rubber band box 

20 will disappear but the component's x and y resources will be internally updated. In either case, the 
developer will have to switch to test mode to view the runtime position of ail the active interface 
components. 

Interface Editor Active Interface Window - Test Mode. When in test mode, the default behavior 
appropriate to the user interface component takes place for all mouse and keyboard events. For example, if 

25 a choice In a Menu Bar has a pulldown associated with it, pressing mouse button 1 with the mouse po inter 
in the choice displays the pulldown. Also, when using the window manager to move a primary window, 
secondary window, dialog box. or message dialog, the user interface component's x and y resources will be 
updated . And, when changing the x and y resources via the move operation or resource editor, the actual 
user inter face component will move to show it new position. 

30 The Active Component Resources in window FIG 9 allows the developer to view and select for 
modification the resources of the active component. It contains a label which identifies the current 
component and its type, along with a list of labels which contain the names and current values for the 
resources of the current component. By placing the mouse pointer over the desired resource and pressing 
mouse button 1 , the Interface editor will activate an editor for each unique component resource type. For 

35 example, there is a single color resource update tool which is used to change any component color 
resource such a s foreground color, background color, etc. See FIG 11 . 

If the size of Active Component Resources window is increased, the dialog will adapt to display more of 
the component's resources. The opposite is also true if the dialog's size is decreased. Resource changes 
made via the resource editors described below are propagated to all descendants of the active component 

40 when all the following conditions are true: 

0 the resource being changed is a color, font or background pixmap. 

0 the user interface component for which the resource is changed is a parent of other components, 
o the user interface component and the sub-hierarchy below it (as opposed to just the parent 
component itself) are currently selected (see Component Selection/Activation above for a discussion 
45 of how components and sub-hierarchies are selected). 

For example, if a group box and its descendants are selected in the user interface component hierarchy 
display area, a change to the font of the group box will cause the same font resource value to be 
propagated to each descendent of that group box. 

The following describes an example of using a resource editor dialog box. FIG 10 shows the text 
50 resource box editing the title resource associated with the primary window. The text resource editor dialog 
is used to modify a component resource consisting of one or more lines of text that are to be treated as a 
single unit (as opposed to a list). The Text Resource Editor is used to modify component names, button 
label s. etc. The current value of the component resource being modified is made available for editing in 
this dialog. In addition, the editor shows the specific name of the resource being edited (e.g., "Title"). 
65 Once the developer has completed all desired changes, selection of the OK button will update the 
cunrent component to reflect the change and remove the text resource editing dialog from the display. If a 
single line resource is being edited, pressing the enter key will also update the resource value and remove 
the dialog. Selection of the Cancel button will also remove the editing dialog from the display but leave the 
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value of the selected component resource unchanged. If the resource to be edited consists of more than 
one line, a scrolled window containing multiple lines is presented: otherwise a single line text entry field is 
shown. Note: Only the first line of a text resource is displayed in Active Component Resources window, with 
the number of characters shown limited by the width of the Active Component Resources window. Another 

5 example of a resource editor is shown in FI6 11. The color resource editor dialog is used to modify 
component color resources. Color resources include foreground and bacl^ground col or, shadow colors etc. 
This dialog displays a grid of radio buttons, one for each available named color, in the color that 
corresponds to the named color. The resource's current color name is displayed and the matching radio 
button is set to indicate that color as the current color. The developer changes the resource color by 

70 selecting the desired color's radio button. The user Interface component Is updated as the developer 
selects each radio butt on. Selection of the default radio button will set the resource value to "Default". 
This, in turn, will retrieve the user preference value to set the color resource. If the developer selects the 
OK button or presses the enter key. the dialog is removed from the display and any changes made to the 
resource remain. Selection of the cancel but ton will remove the dialog from the display and the resource 

75 will be restored to the color the resource had when It was selected for modification. 
Other resource editors are available to modify other types of resources. 

THE USER INTERFACE SERVER (UlS) 

20 As shown In FIG la the user interface server 48 provides the applications with the ability to load user 
interfaces which have been previously created and stored in the display object store 46 by the interface 
editor 49. The user Interface server 48 provides a run-time interface between the window management 
system 58 and the applications. The user interface server 48 is capable of handling multiple applications 
each with multiple user interfaces. 

25 The user interface server also provides applications with the ability to load a portion of an interface and 
attach it to a previously loaded interface. Each application 50, 53, 54 can modify interfaces which have been 
previously loaded by the user interface server 48 from the display object store 46 and can control the 
behavior of the interface. Although different applications 50, 53, 54 can share the same user Interface as 
stored in the display object store 46, they may each separately tailor the interface after it Is loaded by the 

30 user interface server 48. The user interface server 48 loads separate copies of each shared interface into 
the working memory area 78 for each application currentiy using the shared interface. Since applications 
may have several user interfaces it is possible that multiple copies of a user interface will be loaded for a 
single application. Each would be separately modifiable by the application. 

As shown in FIG la, the applications 50, 53, 54 are coupled to the user interface server 48 via 

35 interconnecting means 56. Each application issues commands to the user interface server via the user 
interface server Interface 52. The user interface server interface 52 is part of the application. The user 
interface server interface 52 provides a set of commands that permits each application to Individually 
control the behavior of their user interfaces and receive information from the user Interface server 48. The 
user interface server interface 52 provides each application with the functions necessary to control and 

40 modify its user interfaces. Each application can issue any of the set of commands to be carried out by the 
user interface server 48. This provides an application development language by which each application has 
the ability to control the behavior of its user interfaces. 

The user interface server 48 services the commands issued by each application. These commands can 
include: initialization; loading of user interfaces; attaching portions of user interface s to previously loaded 

45 user Interfaces; deleting loaded user interfaces or portions of loaded user interfaces; moditication of loaded 
interfaces; querying; Initializing default values; and the displaying and undisplaying of user interfaces and 
user Interface components. It is the application's use of these commands that provide for dynamic use of 
user interfaces and window management system independence. 

Additionally, the user interface server interface 52 also provides a mechanism for each application to 

50 receive appropriate information about user actions. Suppose application A currently has displayed a user 
Interface that contains a list of menu items. If a user selects a menu item shown on the display means with 
a mouse, tiie appropriate function In Application A for handling this selection would be invoked in response 
to the user selection. The name of the application function to invoke is provided by means of a callback 
resource associated with the particular menu item. 

55 Interconnecting means 56 also provides the capability for an application to be located on a remote 
system with its user interface presented on the platform containing the user interface serve r 48. The 
remote application communicates to the user interface server 48 via its remote user interface server 
interface to the remote communication adaptor (not shown) which communicates to the local communica- 
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tions adaptor 36 which communicates to interconnecting means to the user interface server 48. This remote 
connection provides for two-way communication. Thus applications do not have to be located in the same 
system as the user interface server. This flexibility is due to the server nature of the user interface server. 
The window management system 58 permits the user interface server 48 to show results in different 

5 areas of the display, to resize the screen areas In which those user Interfaces of particular applications are 
executing, to pop-up and to pull-down menus. The window management system is a resource manager in 
much the same way that an operating system is a resource manager, only the types of resources differ. 
The user Interface server 48 utilizes the window management system's 58 capability to manage display 
resource s. The user interface server 48 interacts with the window management system 58 as an agent for 

10 the applications 50. 53. 54. 

Although the user Interface server 48 would have to be modified to work with a different window 
management system, the applications themselves would not. Each application's user Interface s are 
controlled and managed via commands issued through the user interface server interface 52. These 
functions implemented by these commands are supported by the user interface server on any window 

75 management system to which the user interface server has been ported. Thus the user Interface associated 
with each application is Independent of the window management system. 

An important advantage of this Invention is that the application can dynamically specify sharing. Most 
applications have user Interfaces that consist of sub-hierarchies of user interface components. Often a sub- 
hierarchy is only needed on demand, as the result of a user selection within the user interface. For 

20 example, assume a user interface contains a menu with a list of several choices, one of which when 
selected causes a print function to be invoked. The corresponding application may be set up so that If t he 
user selects the print function the application will command the user Interface server to load the print sub- 
hierarchy from the display object store and attach it to the appropriate location of the already loaded user 
Inter face containing the menu list and then display the print sub-hierarchy. If the user then makes a 

25 selection that ca uses the print function to no longer be needed (i.e. exit print function) the application can 
issue a command to the user interface server to delete the sub-hierarchy from the working memory area or 
to modify the working memory area so that the sub-hierarchy is no longer displayed. 

THE APPLICATIONS 

30 

Applications issue commands to the user Interface server and receive event information from the UlS. 
Each application can be run in either a compiled or an interpretive environment. Compilation is a process 
that translates a computer program, a set of abstract instructions. Into a series of machine instructions that 
can be executed by the computer. Software development environments that require an application to be 
36 compiled before It can be run are referred to as compiled environments. In contrast, some environments 
allow the developer to run an abstract series of Instructions directly, providing an interpreter to translate the 
abstract instructions into machine language as the program is being executed. Such environments are 
referred to as interpretive. 

Applications may have one or more user interfaces in which they communicate to the developer. An 
40 application with several user interfaces can load all its user Interfaces when the application Is initially 
invoked or it may load the interfaces as required by the user's selections. Each application controls the 
display and appearance of their user interfaces by issuing commands to the UlS. The set of commands 
available to the application is referred as the UlS Interface. The UlS Interface contains the cod e for 
invoking the UlS to carry out the commands. The sequence by which the UlS Interface commands are 
45 issued by the application and the specification data associated with each command determine how the user 
Interfaces will appear on the screen and determine which application functions will respond to user 
generated events. 

From the application developers point of view, the user interface server 48 provides a front-end to the 
windowing system; it loads the user interface at runtime, controls the display o f the user interface (sending 
50 commands to the windowing system which actually renders the user interface on the display), and provides 
the mechanism for Interaction between the user Interface and the application function. 

THE DISPLAY OBJECT STORE (DOS) 

55 The user interfaces are stored externally from the UlS. window management system, and the 
applications. FIG 3 depicts the display object store containing several user interfaces. The user Interfaces 
may be stored in a file or a database. The UlS can retrieve user interfaces from the display object store or 
have the display object store retrieve a specified user interface or a list of user interface names. A user 
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interface in the display object store contains general information about the user interface, information about 
the individual components, and defines the relationship amongst the components within the user Interface. 

TTie user interfaces are stored externally from the applications and the UlS in the DOS. It is the external 
nature of the display object store that facilitates sharing and dynamic use of the user interfaces. The user 

5 interfaces can be stored as flat files or in a database. A flat format is a sequential or one-dimensional 
representation of the two-dimensional user interface hierarchy. 

User interface hierarchies are easily represented in computer memory. For Instance, using structures 
containing pointers to point from parent components to child components. However, files an d some 
database structures do not lend themselves to such direct representation, thus the hierarchy has to be 

70 serialized into a one-dimensional representation referred to here as a flat file. Sufficient Information is store 
d in the flat file to recreate the hierarchy later. This information Is often recorded by Including the name of 
the parent of each component with the component. 

As stated previously the UlS utilizes a hierarchical organization of components in the working memory 
area. It is this logical hierarchical organization of the user interface components that is important. One of the 

75 advantages of representing the user interface as a hierarchy of components Is Inheritance. Components in 
the hierarchy can inherit attributes and behavior from parent components. For example, an application may 
have a user interface with a primary window and several secondary windows as children, with a dialog box 
being a child of one of the secondary windows. Under inheritance the dialog box cannot be displayed 
unless the parent secondary window is displayed and the secondary window cannot be displayed unless 

20 the primary win dow is displayed. A person of ordinary skill in the art is capable of determining the 
appropriate conversion from the external DOS format to the UlS internal hierarchical format. It is important 
to note that this invention is not limited to any particular formats for user interfaces whether in the display 
object store or in the working memory area. The exact format for storing the user interfaces is not 
significant as long as the UlS can access the user interfaces as a hierarchy in memory. Of primary 

25 importance in selecting a storage format Is the ability to move the display object store from system to 
system with the applications. 

Although the display object store 46 is shown in FIG 2 as located in RAM 38. the display object store 
46 may be stored on disk, flash memory and/or ROM without loss of functionality. The display object store 
46 may also be located on an entirely different data processing system with access to the display object 

30 store provided by the communications adaptor 36, I/O 30 or the system bus 22. In fact the display object 
store 46 may be located on a file server so that numerous applications operating on different systems could 
utilize the user interfaces as stored in the display object store on the file server. 

THE WINDOW MANAGEMENT SYSTEM (WMS) 

35 

A window management system provides many of the important features of modern user computer 
interfaces. A window management system allows multiple applications to interact with the use r on a single 
computer display, and provides low level functions for the application to display data an d collect input from 
the user. The window management system permits applications to show results in different areas of the 

40 display, to resize the screen areas in which those applications are executing, to pop-up and to pull-down 
menus. The window management system is a resource manager in much the same way that an operating 
system is a resource manager, only the types of resources differ. The window management system 
allocates the resources of screen area to various applications that seek to use the screen and then assists 
In managing these screen areas so that the applications do not interfere with one another. The window 

45 management system al so allocates the resources of interaction devices to applications that require user 
Input and then routes the flow of input Information from the devices to the event queue of the appropriate 
application for which the input is destined. 

A window management system typically has two important parts, the first is the window manager with 
which the end user interacts to have windows created, resized, moved, opened, closed a nd so on. The 

50 second is the underlying functional component, the window system, which actually causes windows to be 
created, resized, moved, opened, closed and so on. The window manager can be built on top of the window 
system. The window manager uses services provided by the window system. The window manager window 
system as a command line interpreter Is to the underlying operating system kernel. Applications are built on 
top of the window management system. The applications built on the win dow management system are 

55 sometimes called clients, which in turn use the capabilities of the window management system, itself, 
sometimes called the server program. In some client/server window management systems, such as the X 
Window system, the window manager itself appears to the window system as Just another client program. In 
other systems there Is a closer relationship between the window manager and the window system than 
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there is between a client and server. Note that multiple clients are supported by a single server, versus link 
ed code which requires a one to one relationship. The client/server model permits clients and servers to 
execute on different platforms, communicating via interprocess communications or other interconnecting 
means. The use of interprocess communications allows computation intensive applications to reside on a 
5 powerful computer while the user interacts with the application from a workstation. In this regard, the 
client/server model Is just a sophisticated instance of a virtual temninal protocol; such protocols, in general, 
share this advantage. 

A window management system does not need to be built on the client/server model . For instance, the 
Macintosh has no well defined separation between the window manager and the win dow system. Such 
10 separation was not necessary for the single active process, single processor design of the Macintosh], and 
would have led to additional runtime overhead. Of course, in window management systems that provide for 
the use of interprocess communications between the window manager and the window systems, such as X 
Windows, News and Andrew, the interface must be designed to minimize communication delays . 

Applications sharing a common window system can utilize a common interactive technique toolkit built 
fs for the WMS to assure a common look and feel. An interactive technique toolkit consists of a set of 
subroutines that provide different types of display objects. 

Interactive technique toolkits, which are subroutine libraries of interaction techniques, are mechanisms for 
making a collection of techniques available for use by applications. By using interactive technique toolkits, a 
consistent look and feel among applications sharing a common WMS can be insured. For instance, the 

20 menu style used to select window operations should be the same style used within all applications. Basic 
elements of the toolkit can include menus, dialog boxes, scroll bars, file selection boxes a nd the like, all 
which can conveniently be implemented in windows. Interactive technique toolkits are avail able for specific 
WMSs. Widely used toolkits include the Andrew Window Management Systems Toolkit, the Macintosh] 
Toolkit, OSF/Motif and Interviews toolkits for use with the X Windows system. Also XRAY a nd CLUE. 

25 Several toolkits implement Open/Look on both X Windows and News, Presentation Manager and the Sun 
View Window Management Systems Toolkit. 

HOW THE INVENTION IS USED - EXAMPLE OF OPERATION 

30 This section presents an overview how a developer would use the interface editor's to create a user 

interface. 

FIG 12 depicts the primary window as the "Menu bar" component type on the component creation control 
panel Is selected by the developer. The developer, in this example, clicked on the "Menu_bar" option to 
select the "Menu_Bar" component type. Notice that since a new user interface is being created that only 

35 "PrimaryWindow" component is shown in the component hierarchy display area 94 and that it is highlighted 
indicating that it is the active component and the status line Indicates that It Is the active parent. 

By selecting the "Menu bar" option the developer has indicated a desire to add a menu bar to the 
current Interface. FIG 13 shows the hierarchy display area has been updated to reflect t hat the Menu Bar 
has just been added. Notice that the Menu_Bar1 , the menu bar just added has been designated the active 

40 parent This is not required and the active parent could remain the primary window with other components 
being added to it as children. The developer next clicks on "menu choice" on the component creation 
control panel to add a choice to the menu bar. 

FIG 14 shows the component hierarchy display area has been updated to reflect that the Menu Choice 
has been added. Since the developer has not specified names for the user interface components they are 

45 shown with the default names assigned by the interface editor. 

FIG 15 shows the WYSIWYG representation of the current user interface with the primary window, the 
menu bar and with a single menu choice components in the active interface window. The user interface 
components of the current user interface are shown as they will actually appear when interface is run from 
an application using the user Interface server. The choice's label ( "Menu Choice") was selected by default 

50 as was the title ("Active Interface"). 

To change the menu choice label to something meaningful to the developer's application, the developer 
selects the label resource of the MenuChoicel component from the Active Component Resources window. 
The developer is then presented with a dialog box for editing the label, and changes the label to 'File' as 
shown in FIG 16. The active interface window Is automatically updated to reflect the new label as shown In 

55 FIG 17. Similarly the developer changes the component name from MenuChoicel to file by s electing and 
editing the name resource. The component hierarchy display area is automatically updated to reflect the 
name resource change. 
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In a similar fashion the user adds menu choices of *Edit\ View* and 'Options* resulting In a WYSIWYG 
Interface depicted In FIG 18. The component hierarchy display area corresponding to this display Is shown 
in FIG 19. Note that the component hierarchy display area was updated automatically to reflect the 
additions and the name resource modification of the new choices. The entire interface editor with the three 

5 windows Is shown in FtG 20. 

The developer now wishes to define a pulldown which is to be associated with the 'RIe' option on the 
main menu. To do so the developer clicks on the box labeled 'RIe' In the component hierarchy display 
area, selecting it as the active component. The interface editor responds by highlighting the box represent- 
ing the "RIe' menu choice. This action makes the 'File' menu choice the current parent, allowing the 

70 developer to add a pulldown and have it associated with the 'File' choice. The pulldown menu Is added by 
clicking on the "Pulldown Menu" component type displayed on the component creation control panel. The 
developer now adds pulldown menu choices to the pulldown menu. The developer edits the name and label 
resources for these pulldown menu choices by selecting the menu choice In the hierarchy display area by 
clicking a mouse over the desired component and then selecting the appropriate resource in the Active 

15 Component Resources window and editing the resource. Changes are reflected in the component hierarchy 
display area and in the Active Interface Window. The Interface editor's primary window is shown in FIG 21 
where the developer has added the pulldown menu and the pulldown menu choices 'New', 'Open', 
'SaveAs', 'Print' and 'Quit'. Note that in FIG 21 the developer has already clicked on the box labeled 
"PrimaryWindow" In the component hierarch y display area, selecting it as the active component. The 

20 Interface editor responded to this selection by highlighting the box representing the 'PrimaryWindow' menu 
choice. This action makes the 'PrimaryWindow' menu choice the current parent. 

Thus far the user has been in the interface editor design mode. FIG 22 shows t he Interface editor's 
primary window where the developer had selected the 'Options' menu choice from the menu bar and has 
selected the test mode via the options pulldown menu. In test mode the default mechanisms associated 

25 with mouse actions apply. 

This means that when the developer clicks on the 'File' menu choice in the Active Interface Window, the 
associated pulldown Is displayed. In design mode, clicking on the 'File' in the Active Interface Window 
menu choice would not cause the associated interface component to appear. The active interface area Is 
shown in FIG 23 after the developer has clicked on the 'RIe' menu choice. 

30 To save the user Interface the developer could select the 'Interface' option from the interface editor's 
primary menu bar and click on the 'Save' choice. See FIG 24. The user interface is then saved In the 
display object store. The developer may be prompted to name the user interface. The user interface 
created In the above example can be loaded back into the Interface editor for further editing, or can be used 
simultaneously by one or more applications on one or more windowing systems. 

35 To exit the Interface editor the developer selects the 'Interface* option from the interface editor's 
primary menu bar and click on the 'Exit' choice. See FIG 24. The developer could then later reinvoke the 
Interface editor at a later time as described above and retrieve the previously created user interface and 
edit or modify the user Interface. In editing the retrieved user interface the developer can use any of the 
commands described above. The edited or modified user Interface could then be saved In the display 

40 object store as a new user Interface or It could replace the previously created user Interface. 

ADVANTAGES OF THE INVENTION 

The present invention solves the identified drawbacks of the prior art. It provides the application 
45 developer with a means of creating and editing user Interfaces that are Independent of any particular 
window management system. The user interfaces created and edited can be used without compilation. 
Furthermore, a single representation of the user interface is used for all window management systems. This 
allows for ease in maintenance and version control of the user Interface. When changes are require d to the 
user interface, the changes can be made by modifying the user Interface as stored in the display object 
50 store. Changes made do not require recompilation. 

The user interfaces created and edited by the interface editor can also be us ed by interpretative 
applications without requiring special application code to link the interpretive application to the user 
Interfaces. This frees the application developer of the need to provide a programmatic Interface between the 
application and the interpretive environment, 
55 This invention relieves the application developer of the need to write in a com piled language, or to 
know the details of any particular windowing system or Interaction toolkit. In addition, the user interface 
portion of the application can run without modification on any window management system to which the 
user interface server has been ported. By eliminating the need for compiling the user interface, several 
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disadvantages are avoided. Compilation of the user interface typically creates a large executable that link s 
in the windowing system libraries. The large executable takes a long time to load at runtime and requires a 
large allocation of memory. This adds to the execution time of the application. 

This invention does not require compilation of the user interface, nor does it require duplicate 
5 representations of the same user interface for different window management systems. One alternative 
approach to window management system independence, requires a high level language representation plus 
one compiled executable for each windowing environment. This invention does not require compilation and 
one representation provides for a user interface on any window management system to which the user 
interface server has been ported. 

10 

ALTERNATIVES AND CLOSING 

The present invention could be implemented In many ways. The present invention provides for a user 
interface builder that provides a higher level of abstraction than the underlying windowing system such that 

15 a) the user interface Is build interactively and b) the user interface is independent of the windowing system 
and 2) a runtime environment that loads interfaces and supports the interaction between the user and the 
application such that a) a mechanism is provided for the application to dynamically modify and query the 
user Interface and b) different applications can share the same user interface. The present Invention is not 
de pendent on the implementation language, hardware or software platform, window management system, 

20 user interface toolkit, or the specifics of the look and feel or the exact functions provided. 

The present invention provides an interface editor for creation and editing of user interfaces and for 
storing and retrieving user interfaces from a display object store. A user interface server provides 
applications with the ability to dynamically load user interfaces and portions of user interfaces from a 
display object store. The present invention can be implemented on a variety of hardware, software, and 

25 Window Management Systems. For example, it could be implemented on a personal computer running 
Windows] or Presentation Manager with OS/2 or on a Sun or HP workstation running X windows for Unix, or 
on an IBM RISC System/6000 workstation running AIX and AlX-Windows. 

While the present invention has been described with reference to structures disclosed herein, it Is not 
confined to the details set forth and this disclosure is intended to cover such modifications or changes as 

30 may come within the purposes of the improvements or the scope of the following claims. 

Claims 

1. In a data processing system which includes a computing means, a memory means, a display means, 

35 input means interconnected by a system bus, comprising, 

a display object store in the memory means which contains a plurality of user Interfaces, wherein each 
user interface contains a plurality of hierarchically related user interface components; 
a interactive editor means in the memory means coupled to the display object store, said interactive 
editor having a primary window containing a main menu, a status line, a user interface component 

40 creation control panel and a user interface component hierarchy display area, displayed In a firs t 
portion of the display means, 

the interactive editor means responsive to a initial developer selection of a user interface, retrieves the 
user interface from the display object store and loads the user Interface Into a working memory area, 
displays a hierarchical representation of the components of the retrieved user interface in the user 
45 interface component hierarchy display area, displays a WYSIWYG representation of the user interface 
in a second portion of the display means, 

the interactive editor means responsive to one or more editing commands Input by the developer using 
the Input means, so that for each said editing command the user interface in the working memory area 
is modified, 

50 said editing command causing updating of the user interface component hierarchy display area and the 
WYSIWYG representation of the user Interface in the second portion of the display means to reflect the 
modifications; and 

storing said modified user interface in the display object store when the developer is finished editing. 

65 2. The system in claim 1 wherein the interactive editor means is coupled to a win dow management 
system such that the window management system controls displaying on the display means. 
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The system in claim 1 wherein the interactive display means also displays a list of resource names and 
associated resource values for a component selected by the developer in a third portion of the display 
means, and were the editing commands permit modification of the resource values selected from the 
list. 

A system for the Interactive editing of a user interface, comprising: 

a) a computer having a display and stored tasks wherein the appearance of said user interface and 
method for manipulation are defined by a hierarchy of user interface components each component 
having associated resources, 

b) an interactive display editor for defining the hierarchy of user interface components and their 
associated resource values, 

c) the interactive display editor storing the defined user Interface consisting of the hierarchy of user 
interface components and their associated resources values in a display object store, and 

d) user interface server using said user interface as stored in the display object store to render said 
user interface upon the display and enable user interaction with said user interface . 

An interactive method of editing a window system independent user interface in a computer system 
which includes a computing means, a memory means, a display means, Input means interconnected by 
a system bus, tiie user interface being represented by a plurality of hierarchically related user interface 
components, each component having a plurality of resources tiie method comprising the steps of: 
retrieving a first user interface from a display object store in the memory means: 
displaying in a first window one or more editor commands; 

displaying In a second window a hierarchical representation of the user interface components of the 
first user Interface; 

displaying in a third window a WYSIWYG representation of the user Interface; 

editing the user interface in response to editing commands selected by a developer in the first window; 

storing the edited user interface in the display object store. 

An interactive method of creating a window system independent user Interface in a computer system 
which includes a computing means, a memory means, a display means, input means interconnected by 
a system bus, the user interface being represented by a plurality of hierarchically related user Interface 
components, each component having a one or more resources, the method comprising the steps of: 

a) displaying in a first portion of tiie display means, a primary window containing a main menu, a 
status line, a user interface component creation control panel and a user interface component 
hierarchy display area; 

b) creating a active user Interface hierarchy in the memory means having a root user interface 
component and displaying said root user interface component as a symbol in the user inter face 
component hierarchy display area, where the root user Interface component is designated a active 
component; 

c) displaying a WYSIWYG representation of the active user Interface hierarchy In a second portion of 
the display means; 

d) adding a user interface component to the active user interface hierarchy, as a child of the active 
component, when a developer selects a user interface component type from the user interface 
component creation control panel; 

e) updating the user interface component hierarchy display area to display tiie added user Interface 
component as a symbol with a Interconnection symbol to the active component; 

f) updating the WYSIWYG representation of the active user interface hierarchy in the second portion 
of the display means; 

g) repeating steps d) through f) until the developer has added all components of the user interface; 

h) storing the user interface represented by the active user interface hierarchy in a display object 
store. 

The method of claim 6 where in step e) the added user Interface component Is designated the active 
component 

The method of claim 6 wherein the developer designates the active component before selecting the 
user interface component type, where the designation is accomplished by the developer selecting the 
symt)ol In the user interface component hierarchy display area associated with the active component to 
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be designated. 

9. The method of claim 6 wherein a component resource list having a resource name and an associated 
resource value is displayed for the active component in a third portion of the display means said 

5 resource list: 

permitting the developer to select resources and modify the value of the selected resource for the 
active component In the memory means, and In response to such modification updating the user 
interface component hierarchy display area and the WYSIWYG representation of the active user 
interface hierarchy on the display means to reflect the modified resource value. 

10 

10. The method of claim 9 wherein in response to the developer selecting a resource a resource editor 
associated with the resource is invoked to allow the developer to interactively modify the resource 
value. 

15 11. An interactive method of creating a window system independent user interface in a computer system 
which includes a computing means, a memory means, a display means. Input means interconnected by 
a system bus, the user interface being represented by a plurality of hierarchically related user Interface 
components, each user Interface component having a one or more associated resources, the method 
comprising the steps of: 

20 a) displaying in a first portion of the display means, a primary window containing a main menu, a 

status line, a user Interface component creation control panel and a user Interface component 
hierarchy display area; 

b) creating a active user Interface hierarchy In the memory means having a root user interface 
component and displaying said root user interface component as a symbol In the user inter face 

25 component hierarchy display area, where the root user interface component is designated a active 

component, displaying a WYSIWYG representation of the active user interface hierarchy in a second 
portion of the display means displaying a list of resource names and associated resource values for 
the root component in a third portion of the display means; 

c) adding a user Interface component to the active user interface hierarchy, as a child of the active 
30 component, when a developer selects a user interface component type from the user interface 

component creation control panel, updating the user Interface component hierarchy display area to 
display the added user interface component as a symbol with a interconnection symbol to the active 
component, and updating the WYSIWYG representation of the active user interface hierarchy in the 
second portion of the display means to reflect the added user interface component; 
35 d) designating the added user interface component the active component and displaying the list of 

resource names and associated resources values for the active component In the third portion of the 
display means; 

e) permitting the developer to change a resource value In memory associated with the active 
component by a resource editing means; said resource editing means causing the updating of the 

40 WYSIWYG representation of the active user interface hierarchy, the active component In the user 

interface component hierarchy display area, the associated resource value in the third portion of the 
display means to reflect the changed resource value; 

f) repeating steps c) through e) until the user interface is completed; 

g) storing the user interface represented by the active user Interface hierarchy in a display object 
45 Store. 

12. An interactive method of editing a window system independent user interface in a computer system 
which includes a computing means, a memory means, a display means, input means interconnected by 
a system bus, the user interface being represented by a plurality of hierarchically related user Interface 
50 components, each user interface component having a one or more associated resources, the method 
comprising the steps of: 

a) displaying in a first portion of the display means, a primary window containing a main menu, a 
status line, a user interface component creation control panel and a user interface component 
hierarchy display area; 

55 b) retrieving a user Interface from a display object store. In response to a developer selection In the 

primary window; 

c) creating a active user interface hierarchy in the memory means from the retrieved user interface, 
displaying a hierarchical representation the components of the active hierarchy in the user interface 
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component hierarchy display area, displaying a WYSIWYG representation of the active user interface 
hierarchy In a second portion of the display means, displaying a list of resource names and 
associated resource values for the root component in a third portion of the display means; 

d) editing the active user interface hierarchy in the memory means in response to developer 
s selections, updating the user interface component hierarchy display area, the WYSIWYG representa- 
tion of the active user interface hierarchy in the second portion of the display means, and the list of 
resource names and associated resource values in the third portion of the display means, to reflect 
the editing; 

e) storing the user interface represented by the active user interface hierarchy in a display object 
10 store after the developer has completed editing the active hierarchy. 
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